Flavor access is currently controlled via private/public flavors and the
flavor access list aka `FlavorProjects`. To restrict access to a flavor,
it must be turned private and access must be granted individually to
each project.

To support external customers, we want to restrict access to
certain flavors for arbitrary domains while keeping these flavors
publicly accessible on other domain without additional configuration
needs. Additionally, we want to enable project owners to configure
project-specific flavor access.

This adds flavor permission rules as a new mechanism for controlling
flavor access. These rules are independent of flavor privacy and the
flavor access list. So a flavor is only available to a project if
allowed by both the flavor permission rules and the flavor access list.

Each flavor permission rule has a `project_id`, a scope (`domain` or
`project`), an optional `flavor_id` and a `type` (`allow` or `deny`).

The two scopes of flavor permission rules are derived from the project
hierarchy:
- `domain` scope rules have a domain `project_id` and apply to all
  projects within that domain
- `project` scope rules have a `project_id` of a non-domain project,
  apply only to that project itself and are not inherited by
  sub-projects

A flavor is permitted for a project if it is permitted at both the
domain scope and the project scope. Rules without a `flavor_id` define
the domain's or project's default behavior for flavors without a
flavor-specific rule. If a domain or project does not have a default
behavior rule, then all flavors are permitted at that scope by default.

There is at most one flavor permission rule for each combination of
`project_id` and `flavor_id`. Consequently, a flavor is only denied at a
scope if for the corresponding `project_id`:
- there is a `deny` rule matching the `flavor_id`
- OR there is a `deny` rule without a `flavor_id` AND there is no
  `allow` rule matching the `flavor_id`

Change-Id: I5e1332d111c07ee714f2965c558f393c8568ffaf